Currently, "Information superhighway" and "multimedia" are probably the most often spoken and least often understood aspects of a coming revolution in data communication. Although issues specific to an information superhighway are beyond the scope of the present discussion, interactive multimedia systems are very much within the present scope.
An interactive multimedia system is broadly defined as a system capable of processing, storing, communicating and coordinating data pertaining to visual information, aural information and other information. Visual information is generally divided into still picture or graphics and full motion video or animation categories. In the vernacular of those involved in multimedia, such visual information is generically referred to as "video." Aural information is generally divided into speech and non-speech categories and is generically referred to as "voice." "Other information" is directed primarily to computer data, often organized in files and records, and perhaps constituting textual and graphical data. Such computer data are generally referred to as "data."
To date, multimedia has, for the most part, been limited to stand-alone computer systems or computer systems linked together in a local area network ("LAN"). While such isolated systems have proven popular and entertaining, the true value of multimedia will become apparent only when multimedia-capable wide area networks ("WANs") and protocol systems are developed, standardized and installed that permit truly interactive multimedia. Such multimedia systems will allow long distance communication of useful quantities of coordinated voice, video and data, providing, in effect, a multimedia extension to the voice-only services of the ubiquitous telephone network.
Defining the structure and operation of an interactive multimedia system is a critical first step in the development of such system. Accordingly, before entering into a discussion herein of more specific design issues, it is important to discuss more general questions that need to be resolved concerning design objectives of the system as a whole and some generally agreed-upon answers and specifications.
Interactive multimedia may be thought of as an electronic approximation of the paradigm of interactive group discussion. It involves the interactive exchange of voice, video and data between two or more people through an electronic medium in real time. Because of its interactive and real-time nature, there are some stringent requirements and required services not normally associated with multimedia retrieval systems. Some of the more obvious examples of those requirements and services include latency (transmission delay), conferencing, availability ("up-time") and WAN interoperability.
The evolution of existing private branch exchange ("PBX") and LAN topologies towards a composite interactive multimedia system based upon client/server architectures and isochronous networks is a natural trend. However, to merge the disparate mediums of voice, video and data successfully into a cohesive network requires that three fundamental integration issues be defined and resolved. The first of the fundamental integration issues is quality of service ("QoS"). QoS is defined as the effective communication bandwidth, services and media quality coupling of separate equipment or "terminals" together and the availability ("up-time") of the same. QoS parameters are divided into four groups: 1) terminal QoS, 2) network QoS, 3) system QoS, and 4) availability requirements. Thus, QoS parameters must be defined for both terminal equipment ("TE") and network equipment ("NE") governing the communication of data between the TE. System QoS is derived from a combination of terminal and network QoS. The suggested values for QoS parameters are considered to be a practical compromise between required service quality, technology and cost. See, Multimedia Communications Forum ("MMCF") Working Document "Architecture and Network QoS", ARCH/QOS/94-001, Rev. 1.7, MMCF, (September 1994) and ITU-T Recommendation I.350 "General Aspects of Quality of Service and Network Performance in Digital Networks, including Integrated Services Digital Networks ("ISDNs"), (1993). The following Table I summarizes some suggested parameters for terminal QoS.
TABLE I ______________________________________ Terminal QoS Parameters Parameter Parameter Type Parameter Value Explanation ______________________________________ Audio Frequency 3.4 kHz Optimization is for Range voice, and is consistent with existing Legacy voice systems. Audio Level -10 dBmO Optimization is for voice, and is consistent with Legacy voice systems. Audio Encoding G.711 (8-bit pulse Consistent with code modulation Legacy voice ("PCM")) systems. Video Resolution .gtoreq.352 .times. 288 (SIF) Minimal acceptable size for video conferencing. Video Frame Rate .gtoreq.20 frames per Minimal second (fps) optimization for detection of facial expression transitions. Voice/Video &lt;100 milliseconds A differential Intramedia- (ms) delay greater than Intermedia 100 ms between voice Differential Delay & video is noticeably significant. Video Encoding H.261 & Motion H.261 meets WAN Picture Experts interoperability, Group ("MPEG")-1 MPEG-1 is more consistent with desktop trends and quality requirements. Intramedia Latency &lt;100 ms The delay of the TE (TE) itself for encoding and framing purposes. User Data Rate .gtoreq.64 kbps Minimal acceptable data bandwidth for data sharing applications. Consistent with ISDN Basic Rate Instrument ("BRI"). Data encoding HDLC encapsulation Consistent with isochronous service bearer channels. ______________________________________
Network QoS parameter requirements consist of those parts of the system that are between two TE endpoints. This includes a portion of the TE itself, the private network (if required), and the public network (if required). Some of the requirements imposed upon the network QoS are a result of the terminal QoS parameters. The following Table II summarizes the network QoS requirements.
TABLE II ______________________________________ Network QoS Parameters Parameter Type Parameter Value Parameter Explanation ______________________________________ Intramedia Latency &lt;50 ms Intramedia latency is (NE) the delay between source TE transmis- sion and destination TE reception; i.e. the delay of NE. Network Capacity .gtoreq.1,536 kbps G.711 Audio (64 kbps), MPEG-1 Video (1,344 kbps), HDLC data (128 kbps). ______________________________________
The system QoS encompasses the terminal and network elements. The particular value critical to the system is the intramedia latency. The following Table III summarizes this value that is the sum of the terminal and network values for the same parameter.
TABLE III ______________________________________ System QoS Parameters Parameter Type Parameter Value Parameter Explanation ______________________________________ Intramedia Latency &lt;150 ms Intramedia latency is (System) the delay between source transmission and destination reception. It includes latency imposed by the source and destination TEs as well as the NE. These latency values might include encoding and decoding delays, transmission delays, and adaptation delays. ______________________________________
The system QoS parameter of Intramedia Latency is the sum of twice the TE and the NE latency. Intramedia Latency parameter value is bounded by voice requirements since latent delay is more readily perceived by the ear than the eye. However, the delay itself is typically a function of video since it is the component requiring the most time for encoding and decoding.
Availability ("up-time") includes several aspects. In particular, the network elements have very strict requirements. These requirements are typical of private branch exchanges ("PBXs") and other private network voice equipment, but are very atypical of Legacy LANs. Most LANs are susceptible to power-losses, single points of failure, and errant TE. An interactive multimedia system must closely follow the availability requirements of the legacy voice systems. The following Table IV summarizes Availability QoS parameters.
TABLE IV ______________________________________ Availability QoS Parameters Parameter Type Parameter Value Parameter Explanation ______________________________________ TE Power 5 watts (W) of This power Requirements phantom power (48 requirement is volts (V)) consistent with the ISDN BRI requirements and will allow the least common denominator of voice to function. NE Power Uninterruptable NE must be UPS Requirements power supply capable including ("UPS") private NE. Single point of 12 Users No more than 12 users failure should be impacted by a single point of failure. Error Free Seconds &gt;99.9% Meets requirement of Ratio ("EFS") random bit error rate of 10.sup.-6. ______________________________________
The availability requirements are defined solely within the context of the private network. Additional availability parameters are discussed in G.821. See also, MMCF Working Document "Architecture and Network QOS", ARCH/QOS/94-001, Rev. 1.7, Multimedia Communications Forum, Inc., (September 1994) and TR-TSY-000499, Transport Systems Generic Requirements (TSGR): Common Requirements, Bellcore Technical Reference, Issue 3, (December 1989).
The second of the fundamental integration issues is network services. Network services include transport services, connection management and feature management. Multimedia communication involves the transmission of data having more varied characteristics than video, voice or data in isolation. Therefore, the manner in which the network transports and manages the flow of video, voice and data is critical to the efficiency, flexibility and overall effectiveness of the network.
Transport services can be categorized into three groups: 1) packet, 2) circuit and 3) cell. The following Table V summarizes different aspects of each of these transport services.
TABLE V ______________________________________ Transport Services Packet Circuit Cell ______________________________________ Typical Ethernet .RTM., ISDN, T1 Asynchronous technology Token Ring .RTM. Transfer Mode Frame Relay .RTM., ("ATM") etc. Media Packet data Isochronous Packet & optimization data (voice, isochronous video) data Transport Multicast, Point-point Point-point, optimization shared medium full-duplex full-duplex, operations low-cost high-speed switching switching Optimized data 1500 bytes 1 byte (voice) 48 bytes size (Ethernet .RTM.) Transport 4.2% (64 bytes none 11.3% (6 bytes Overhead IP) AAL1) Transport Shared Switched Switched Methodology Route Routing Signalling Signalling Methodology (circuit (virtual switching) circuit switching) Typical Widespread. Widespread. Very few Deployment Deployed as Deployed as installations. LAN both public Typically network and deployed as private NE private backbone network ______________________________________
Interactive multimedia requires the usage of an isochronous network because of the QoS requirements for voice and video. While it is possible to construct a packet network with sufficient bandwidth, buffering and intelligence to accommodate synchronous traffic it is considered to be prohibitively expensive and unnecessary. Nevertheless, both the LAN, PBX and WAN require interoperability.
At some point it is expected that the entire private network infrastructure will employ ATM. This will transpire upon the occurrence of several events. First, WANs must adapt to support ATM Points-of-Presence ("POPs"). Second, the telephone must disappear from the premise (replaced by an ATM audio device). Third, packet-based LAN TE must become ATM TE. Fourth, phantom power must be supported to the ATM TE (for availability purposes). Fifth, an 8 kHz synchronous clock must be supported and managed by all ATM equipment. Finally, the price of ATM TE and NE must approach that of Ethernet.RTM., ISDN, and isoEthernet.RTM. equipment.
Regardless of the interim private network infrastructure, ATM is the only backbone solution for the private network. It is the only scalable switching architecture that can transport packet and isochronous data. Furthermore, because it is deployed as a backbone, the aforementioned issues do not apply.
Connection management is the process employed by the private and public network routing functions. Because packet routing is a well established and defined process, it is not discussed further. Connection management within the confines of an isochronous network for interactive multimedia is a newer technology (albeit with old roots) and deserves discussion.
Signalling for circuit and cell switching is best defined by the ISDN signalling standards (see, TR-NWT-000938, Network Transmission Interface and Performance Specification Supporting Integrated Digital Services Network (ISDN), Bellcore Technical Reference, Issue 1, (August 1990)), isoEthernet.RTM. signalling (see, IEEE Proposed Standard 802.9a, "Isochronous services with Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Media Access Control (MAC) service", (December 1994)) and ATM signalling (see, ATM Forum, "ATM User-Network Interface Specification-Version 3.0", (September 1993) and ITU-T Recommendation Q.293x, "Generic Concepts for the Support of Multipoint and Multiconnection Calls"; (1993)). Historically, isochronous networks carry the signalling channel as an isochronous channel. Nevertheless, the signalling function can be shown to be better suited to a packet channel. A hub/routing function is the ideal location to perform the bridging between an isochronous signalling channel and a packet signalling channel. The natural packet protocol choice for a signalling channel is an Internet Protocol ("IETF IP"). Available on most LAN networks, as well as global routing capability, IP greatly enhances the signalling requirement of interactive multimedia.
Feature management consists of the management of those features provided by the private and public network for interactivity purposes. The PBX is followed as a model for interactive multimedia features. The following Table VI summarizes some of the more common features.
TABLE VI ______________________________________ Feature Management System Services User Services Maintenance ______________________________________ Account Codes Buzz Station Automatic Restart Authorization Codes Callback Connection Detail Recording Automatic Number Ca11 Forward Default Identification Installation Direct Inward Call Park Class of Service Dialing ("DID") Direct Outward Call Pickup Hot Configuration Dialing ("DOD") Hunt Groups Call Waiting Multimedia on hold Do Not Disturb/Override Network Numbering Hold/Consultation Plan Hold Number Dial Plan Last Number Redial Shared Resource Multiple/Shared Queuing Call Appearances System Speed Conference Dialing (multiparty) Vacant Number Transfer Intercept ______________________________________
The third of the fundamental integration issues is interoperability. An interactive multimedia system by nature implies interoperability, because a multimedia network as envisioned is too large and far-flung to employ the equipment of only a single supplier. Therefore, standards must be established that allow equipment from different suppliers to interact smoothly. To this end, interoperability must extend to transport mechanisms, signalling and compression standards.
There are certain existing communication technologies that must be supported and others that are used. A truly interoperable interactive multimedia system should guarantee that the physical and logical interfaces of each component adheres to a standard. Prior to 1992, this would have been almost impossible. The present day affords the opportunity to evolve the proprietary telephony of the PBX and the proprietary video of the video conferencing systems into standards-based systems in the same manner that the data systems evolved from proprietary mainframes to the standards-based LAN systems of today. The following Table VII summarizes the required standards of interoperability.
TABLE VII ______________________________________ Interoperability Standards Signalling Compression Transport Standards Standards Standards ______________________________________ isoEthernet .RTM. (IEEE ISDN NI-2 G.711, G.722 802.9a) (Audio) ATM QSIG H.221 (Video) ISDN Q.2931 MPEG-1 (Video) H.320 (Audiovisual) ______________________________________
In addition to the standards required for communications, there are other specifications relating to application programming interfaces for terminal and server control. These include Microsoft.RTM. Telephony Application Programming Interface ("TAPI.RTM."), Novell.RTM. Telephony Service Application Programming Interface ("TSAPI.RTM.") and Microsoft.RTM. Open DataBase Connectivity ("ODBC.RTM.").
Having now set the stage with a discussion of general issues concerning multimedia systems, more specific design issues may now be discussed. The specific design issue of concern is provision of signalling within a private network or a hybrid network and the most proficient manner to accomplish the signalling function between stations or nodes in the network.
Traditionally, isochronous devices such as telephones and video conferencing equipment have signalled in-band. "In-band," in traditional telephony, is defined as use of the same physical path for signalling and user information, such as voice, circuit mode and video data. In contrast, ISDN employs a D-channel, that, although carried over the same physical medium as the B-channels, is logically regarded as a separate channel. In the telephony world, this is defined as "out-of-band" signalling.
However, since signalling services are intermittent processes, it is not necessary to perform this signalling within an isochronous channel. In fact, there is great benefit to be achieved by performing this signalling over a packet service. The key advantages to signalling over a packet service include backbone signalling with simple physical circuit connectivity, routing, remote control, and other operational benefits.
In further support of packet-based signalling, as the size and complexity of modern private and hybrid private/public networks increase, the mechanisms for communication of signalling information from one node to another become increasingly cumbersome and/or expensive. The simplest signalling network is a fully-webbed net in which each node has a direct connection to every other node in the network. This becomes prohibitively expensive as the number of nodes increases. The number of connections needed is equal to (n(n-1))/2, where n is the number of nodes. If the network is configured to use fewer inter-nodal signalling paths, the complexity of the network topology increases significantly as the number of nodes increases. Modern packet technology allows for the establishment of multiple virtual connections without requiring full webbing of the physical connections. The problem is to develop a process for using this capability and applying it to private network signalling procedures such as QSIG.
Assuming that modern technology subsumes a packet-based signalling system that creates virtual connectivity between nodes or partitions in a private or hybrid communication system, there are still other aspects of signalling that require attention. Moreover, one of those aspects of signalling is the separation of the call control process from the circuit connection process. Because these two processes are implicitly separate, simplicity is achieved in call control through non-native networks. By establishing a connection and management link between nodes or partitions independent of the circuit connection, feature management may also be transparently achieved. This is an absolutely essential feature for applications that traverse the public network or other networks not natively supporting the desired feature set.
The Consultative Committee on International Telephone and Telegraph ("CCITT") developed Signalling System Number 7 ("SS7") in 1980 and subsequently modified it in 1984 and 1988. SS7 accomplished separation of the signalling function from circuit connectivity. SS7 supports several functions including call management (including call setup, supervision, routing and billing), transferring account information between nodes, network management and network maintenance. However, application of SS7 is confined to the public network, thereby excluding the private network from feature transparency.
SS7 architecture employs three major components, the Service Switching Point ("SSP"), the Signalling Transfer Point ("STP") and the Service Control Point ("SCP"). When the local exchange network connects via SS7 to the Interexchange Carriers' ("IEC") networks, it will have its own STP and SCP connecting to end offices and the IECs.
The SSP is a tandem switch in the interexchange network or an end office in the Local Exchange ("LEC") network. The STPs are packet switching nodes, and the SCPs are databases of circuit, routing, and customer information.
When the SSP receives a service request from a local end office or a user attached on a direct access line, it formats a service request for the SCP and suspends call processing until it receives a reply. The SSP forwards the request to the STP over the packet network.
The STPs are interconnected over a high speed packet network that is heavily protected from failure by alternative paths. STPs are deployed in pairs so that the failure of one system will not affect call processing. STPs pass the call setup request to an SCP over direct circuits or by relaying it to another STP.
The SCP is a high speed database engine that is also deployed in pairs with duplicates of the database. The database has circuit and routing information, and for customers that are connected through a virtual network, the database contains customer information such as class of service, restrictions, and whether the access line is switched or dedicated. The SCP accepts the query from the STP, retrieves the information from the database, and returns the response on the network. The response generally takes the same route as the original inquiry.
In addition, SS7 uses a layered protocol that resembles the Open Systems Interconnection ("OSI") model, but it has four layers rather than seven. The first three layers are called the Message Transfer Part ("MTP"). The MTP is a datagram service, which means that it relays unacknowledged packets. The MTP has three layers, which form a network similar to CCITT X.25.
The first layer, the signalling data link, is the physical layer. It is full duplex connection that provides physical STP to STP, SCP to SCP, and STP to SCP links. This layer is a data link that has three functions mainly: flow control, error correction, and delivery of packets in the proper sequence.
The signalling network layer routes messages from source to destination, and from the lower levels to the user part of the protocol. Its routing tables enable it to handle link failures and to route messages based on their logical address.
The fourth layer is called the signalling connection control part. It is responsible for addressing requests to the appropriate application and for determining the status of the application. An application, for example, might be an 800 service request. The ISDN service user part relays messages to ISDN users. The user in this context refers to the interface with the end user's equipment and not to the user itself. The ISDN service user part handles call setup, accounting and charging, and circuit supervision for ISDN connections.
Therefore, SS7 establishes a distinct signalling and circuit path between LECs in the public network, and furthermore creates an operational circuit connection prior to transmitting user information. While SS7 frees up bandwidth in the public network by suspending circuit connectivity until the signalling functions are performed, SS7 is not extended to the private network. As a result, feature transparency within a private or hybrid network, or between nodes or partitions, is not accomplished with SS7.
Accordingly, what is needed in the art are a system and method for achieving true endpoint-to-endpoint signalling without the need to establish a user information path until the path is required to complete a call between the endpoints.